Week Of: 2022-02-13
2022-02-18

home/APEX

ניהול תצורת הפיתוח ב-APEX #

Git & code management #

Overview #

ישנן כמה שיטות ואסכולות לניהול הקוד והפיתוח בGit
כל ספריית גיט מכילה את יחידת הניהול הבסיסית ביותר והיא: Git-repository.
בכל Repository יש כברירת מחדל ענף מרכזי-Trunk שלעתים נקרא Main ובדרך כלל נקרא Master. כאשר נוצר Git-Repository הענף המרכזי מוקם כברירת המחדל כענף יחיד שממנו ניתן להקים ענפי משנה.
אסטרטגיית ניהול ה-Git תתייחס לאופן ניהול ענפי המשנה של הענף הראשי.
הענף הראשי מייצג את הקוד המוכן\ראוי להיות ב-סביבת הייצור או זה שנמצא כבר בסביבת הייצור.
האסטרטגיות שיתוארו בקיצור להלן מייצגות את השיטות הרווחות והנפוצות לניהול הקוד בשלבים שלפני העברת הקוד לענף הראשי. בכל ארגון ישנה שיטת הניהול שמתאימה לתרבות הפיתוח בארגון ולאופי המוצר שאותו הארגון מייצר.

1. Trunk-based:
   בשיטה זו, המפתחים השונים מבצעים Push (דחיפת שינויים) ישירות בענף הראשי.
   יתרונות: מאפשר יישום מתודולוגיות של Continues Integration + Continues Deployment, קל לניהול ומייצר חוסר תאימות מזערי ביחס לשיטות האחרות.
   חסרונות: ניהול קוד בתהליכי פיתוח ארוכים, ניהול תצורה וגרסאות, מצריך מומחיות רבה של צוותי הפיתוח
2. Development branch
   בשיטת ניהול זו, הענף Development הוא ענף מרכזי (משני לענף Master) שמנהל שינויי קוד שמפותחים בתהליך ארוך בסביבת הפיתוח כמו פיצ'רים נוספים וכו'. זה מאפשר לקבץ את כלל התוספות שמוכנות להעלאה לסביבת הייצור. בשלב המוכנות של הקוד בענף הפיתוח להעלאה לסביבת הייצור, הוא מאוחד עם הענף הראשי. בדרך כלל, דחיפת קוד לענף זה תבצע פעילות אוטומציה שתבצע העברת הקוד לסביבת הבדיקות.
   יתרונות: קוד יותר מפוקח משיטת Trunk-Based, טוב למערכות קריטיות שיש לבצע בדיקות מקיפות, מיטבי בניהול צוות מפתחים גדול ומיומנות מגוונת.
   חסרונות: מצריך ניהול מפוקח יותר ומשאבי זמן גדולים יותר, מייצר Code-Conflicts יותר מאשר שיטת Trunk-based.
3. Instance-based
   כל סביבת פיתוח מיוצגת בענף משלה והענף המרכזי מייצג את סביבת הייצור. מתוך הענפים המייצגים ייצאו ענפי משנה שייצגו תוספות ורכיבים בתהליך הפיתוח.
   יתרונות: מתאים למעקב שינויים אחרי קוד ארגוני המנוהל בסביבות פיתוח שונות.
   חסרונות: מסובך מאד לניהול, מסבך עד כדי מניעה את אפשרות ההטמעה של CI-CD
4. Feature branch
   בשיטת ניהול זו, הענף המלווה את הענף המרכזי הוא ענף הFeature שמשמש לניהול הקוד לפיתוח פיצ'רים גדולים וקטנים בענפי לוויין לפי הפיצ'ר המפותח. זה מאפשר לכל מפתח שמפתח איזשהו תוספת ליצור לעצמו ענף שיגדיר את התוספת שהוא עמל עליה, בסיום הוא (או הם - במדה ומדובר בצוות שמפתח את התוספת) יאחד את הענף שעליה הוא סיים לעבוד עם ענף ה-Features ובכל תקופת זמן או בהצטברות של תוספות למוצר, הענף יאוחד עם הענף הראשי.
   יתרונות: אידיאלי לניהול קוד במוצרים גדולים, מאפשר ניהול קוד מפוקח ואיכותי יותר ובהתאמה גבוהה יותר לתרבות הפיתוח המקובלת, אידיאלי לארגון עם מפתחים זוטרים (Juniors) שמצריך מעקב ו-CodeReview.
   חסרונות: מצריך תהליכי פיתוח מנוהלים ושיטתיים, דורש השקעה רבה בניהול הקוד ו-Conflict Management.
5. Release branch
   באפשרות זו ענפי המשנה לענף הראשי מנוהלים לפי גרסאות המוצר. כלומר, אין ענף משני תמידי כמו באפשרויות הקודמות. הענפים יכולים להיות לזמן קצר או ארוך אך הם משקפים סט של תוספות למוצר שיועברו אליו כמקשה אחת ובדרך כלל יתועדו כסט של שינויים במבנה ממוספר שמשקף את מהות השינוי וכן תיאור של השינוי שבוצע.
   1 . Hotfix branch
   בשיטה זו, מתייחסים לתיקוני באגים ושיפורים דחופים המתרחשים מעת לעת.
   מוקם ענף לטווח קצר או ארוך שלתוכו מוזנים שיפורים ותיקונים דחופים המבוצעים במוצר קיים ופעיל. הענף מאוחד עם הענף הראשי בתדירות גבוהה יחסית.

Pull Request vs Push #

Push - דחיפת שינויי קוד מספריית הקוד המקומית (Local) לענף הקוד המקביל שבשרת המרוחק (Remote). באפשרות זו, כאשר אין התנגשות בין שורה בקובץ הקיים לבין שורה בקובץ הנדחף, הקובץ הנדחף מחליף את הקובץ הקיים בענף שבשרת המרוחק.
Pull Request - מעין טופס בקשה לדחיפת קוד. המפתח (או המעוניין לדחוף קוד לענף) יילך למערכת הויזואלית של הענף בשרת המרוחק (Remote) ויפתח ממנו טופס בקשה לדחיפת שינויי קוד. ניתן להחיל מדיניות של Code review שיבוצע ע"י מנהל הצוות או גורם אחר שיוגדר מראש או יצויין בבקשה. כמו כן, ניתן להגדיר מדיניות מיזוג קוד, ועוד.

Master branch #

• הענף הראשי ינוהל בשיטת Trunk-based אך עם שינוי - לא תתאפשר דחיפת קוד ישירה (Push) לענף זה.
  לשם הוספת קוד לענף הראשי, יידרשו המפתחים להקמת ענף ייעודי לזמן קצר ולהכניס לתוכו את שינויי הקוד. בסיום, יהיה עליהם לבצע Pull Request מהענף הראשי לשם המיזוג של השינויים שביצעו בענף המשנה לענף הראשי.

Hot fixes and bugs #

מאחר ובטבעם תיקוני הבאגים הינם בעלי קריטיות גבוהה ו-Delivery נדרש גבוה. ישנו ערך גבוה לביצוע דחיפת קוד מהירה ככל הניתן וכן Deploy מהיר של הקוד לסביבות הבדיקות והייצור.
כל תיקוני הבאגים והשינויים שניתן להפיצם לסביבת ה-PROD, יבוצעו באמצעות הקמת ענף ייעודי שייגזר ישירות מהענף הראשי וימוזג לתוכו עם גמר הטיפול בתיקון הבאג או בשינוי.

gitGraph:
options
{
    "nodeSpacing": 100,
    "nodeRadius": 10
}
end
	commit
	branch newbranch
	checkout newbranch
	commit
	checkout master
	commit
	merge newbranch
	branch newbranch1
	checkout newbranch1
   commit
	commit
   checkout master
	commit
	merge newbranch1

Work-Items driven #

השאיפה הינה שכל הפעילות תהיה סביב סיבה ומסובב. הסיבה תהיה במסגרת משימה -Work Item שתנוהל במערכת המשימות של מערכת ה-TFS.
בעקבות המשימה.ות יבוצעו שינויי קוד שהמשימה תוזכר בפעולת ה-Commit שתבוצע בספריית ה-Git. גם אם לא הוזכרה בפעולת ה-Commit, בוודאי שהוזכרה במסגרת הפרטים שימלא המפתח בבקשת ה-Pull Request.
כתוצאה מזה, כשיבוצעו פעולות ה-Build וכן ה-Release יהיה בהם קישור למשימה ובכך כשתובא גרסת הקוד לאישור מנהל המערכת בשלב ה-Release הוא כבר יבין דרך המשימה את מהות הקוד וסיבת השינוי המבוקשת להעלאה.

Features and Development #

בפיתוחים שמשך הזמן שבין התחלת העבודה עליהם לבין זמן הסיום והעלאה ל-PORD הינם ארוכים מסדר גודל של כמה ימים בודדים, יש לנהל את

Long term - Containerization/CDB #

Short term #

Deploy process #

Build and QA #

Release #